1. Field of the Invention
This invention relates to a system and method for locating and correcting errors in a computer program and, more particularly, to a system and method for graphically displaying the structure of a program and controlling the execution of the program during the software debugging process.
2. Description of Related Art
Newly created computer programs often include one or more inadvertent errors. Some software errors can result in the complete failure of a software system, while others may result in incorrect behavior. Although commercial software developers will typically devote 50-70% of their total development time to checking the computer program for errors and correcting those errors, it is almost inevitable that some errors ("bugs") remain even in production versions of the software released to the public. There is, therefore, a great need for an efficient and effective means for "debugging" software.
Debugging is the process of identifying and isolating a software error so that the problem can be corrected. Usually this involves examining the lines of code comprising the software program and/or observing the program's execution to determine the cause for the aberrant behavior.
In the prior art of debugging a program, a user may first read the program line-by-line to try to locate the error or errors. However, following the flow of a program by reading it line-by-line can be extremely difficult and time consuming, even in a relatively simple program. If the program contains many loops, subroutines, function calls, variables and the like, the user may not be able to trace the sequence of program execution, and hence may not be able to determine the effect of the execution of each line of the computer program.
"Debuggers" are software diagnostic tools that provide users with mechanisms for viewing and controlling the execution of programs (including the program states and the values of variables) for the purpose of helping the user identify errors in the program code. With prior art debuggers, the user can control the operation of the defective software program by inputting one or more debug commands and observing the results of the subsequent program execution. For example, a debugger command may be invoked to set a "break point" at a location in the defective program. The effect of a break point is to suspend program execution when the location of the break point is reached. The user can then cause the debugger to display the values of selected variables. State-of-the-art debuggers can also display several lines of disassembled machine code and/or the corresponding lines of source code occurring before and after the break point. Even state-of-the-art debuggers, however, do not predict where and whether a program will branch. Therefore, a deficiency in current state-of-the-art debuggers is that the lines of code which they display following the point of suspension are simply the next consecutively numbered lines of code in the program. Such lines of code may not necessarily be the code which will be executed when the user resumes operation of the program.
Typical debug commands include: a "step command," in which the program is executed one line at a time, with the lines of code possibly being displayed as they are executed; a "watch value command," which displays the changing value of a selected variable while the program is running; a "trace command," which displays a list of active functions on the stack; a "data break command," which stops execution of the program upon the occurrence of a user-selected condition, such as a variable achieving a predetermined value; and an "assign command," which assigns a user-selected value to a variable.
Notwithstanding the wide-spread use of debuggers, debugging can still be difficult and time consuming. One reason for this is that prior art debuggers are text-based, i.e., the debuggers provide the user with information in the form of a series of lines of text and accept commands in a similar format. For example, with prior art debuggers the user may type in an instruction which causes the debugger to place a break point in a particular line of a program or, using a mouse, "point and click" on a line of code to place a break point at the beginning of that line. Upon the occurrence of the break point, prior art debuggers can display lines of text containing the disassembled machine code executed up to the break point, the corresponding line or lines of source code and the value of certain selected variables.
The operation of a debugger at this text-based level has numerous disadvantages. For example, the user must be intimately familiar with the organization of the program being debugged, since the debugger can only display the lines of code comprising the execution path actually traversed by the program; the debugger cannot tell the user which alternative execution paths could have been taken by the program using a different set of input data. Prior art debuggers also do not tell the user which functions could be called by the particular function located at the break point. The user must deduce this information by examining the displayed code. Thus, to fully appreciate the state of the program at the break point, the user must figure out and retain a complex mental picture of the various execution paths which the program might have taken to have reached its current state and the various execution paths it might take once the next debug command causes program execution to resume.
Users of prior art debuggers frequently find themselves in a situation somewhat analogous to a cross-country traveller without a road map who, upon reaching each successive intersection, must ask for the name of the closest town in each direction. Without a road map showing all the roads that lie between the embarkation point and his or her destination, the traveller cannot plan the most efficient way to get to the ultimate destination. Instead, using only trial and error, the traveller can easily get lost, may have to backtrack and will frequently find himself or herself going down dead end streets.
Despite many advances in debugging technology, creating defect-free software is an elusive goal that is far from being achieved. In fact, the trend toward increasingly complex software systems makes achieving this goal even more difficult. Thus, the debugger is one of the most important tools affecting a programmer's productivity. It is surprising therefore, that despite the considerable effort which the software industry has devoted to debuggers, their use is still so cumbersome. (The inventors believe that this results from the fact that prior art debuggers are based upon a model that was developed to support traditional character-based terminals.)
In view of the above, it is clear that there exists a need for an improved debugging tool. In particular, there exists a need for a debugging tool that can abstract critical debugging information from increasingly complex software, display that information in a dynamic and useful graphical format and, in addition, allow the user to control program execution through operations performed directly on the graphical representation of the program.